Process control systems typically include numerous sets of equipment that are used to carry out certain manufacturing or other control processes. The sets of equipment are coupled to controllers that include process control software instructions for manipulating the equipment in certain manners to effectuate the manufacturing or control processes. Process control software may be implemented in software objects run on the controller (or other computer) to perform any of a variety of control functions. For example, in some process control situations, software objects may be arranged to implement different phases, which are generically related to various types of process steps. In particular, a software object that implements a mixing phase may be associated with hardware that carries out a mixing step of a process. As will be understood, each software object implementing a phase performs some discrete function and communicates with other objects to implement a more complex control procedure.
When defining or creating a control procedure to be used in, for example, a batch process, an engineer may start with template software objects having generic control logic therein for implementing a particular function, such as a phase in the batch process. Due to the generic nature of these template software objects, the software objects must be modified or customized based on the particulars of the step that they are to execute before being used ip a particular process control environment. For example, a mixing phase, which is generally adapted to operate mixing equipment, must be customized to operate a particular piece of mixing equipment for particular time durations at particular speeds. Recipes are commonly used to customize or modify phases. As the name implies, recipes include sets of instructions downloaded to process control hardware for carrying out specific tasks such as, for example, making cookies, producing pharmaceuticals or controlling other processes. Recipes are typically more specific than phases and, in fact, include the use of phases therein. For example, a cookie-making recipe may include a mixing step that could be carried out by a mixing phase. However, in contrast to the mixing phase, the cookie making recipe specifies the duration and speed at which mixing should be carried out. Accordingly, the recipe specifies the parameters, that define the operation of the mixing phase.
In a similar manner, software objects may be created for use in safety instrumented systems which are used to provide safety or shut-down procedures or other safety-related functions in a process plant being controlled by a separate process control system. Typically, a safety instrumented system may have one or more safety controllers that are programmed, using safety related software objects, to detect hazardous, dangerous or undesirable conditions within the process plant and to take some action, such as shutting the process down, diverting flow within the process, removing power, etc. when such a condition is detected.
As will be readily appreciated, altering a recipe executed by a process control system or altering a safety system software object could drastically affect the operation of the process control system or the safety system. For example, downloading a recipe that has been accidentally altered or otherwise changed in an unauthorized manner could detrimentally affect the output of a process plant, resulting in products that do not comply with product specifications and, as a result, lost profits. While the alteration of a recipe (which may be implemented as a software object) for products such as cookies may yield cookies that are obviously flawed (e.g., not thoroughly cooked, not having enough chocolate chips, etc.), not all recipe alterations will result in products with immediately perceptible flaws. For example, cookies having too much salt may not be easily discovered during the production process. Consumers, however, may notice the saltiness of the cookies and may complain to the manufacturer, which may then determine that the recipe for the cookies was altered in an unacceptable manner leading to a recall of the cookies. While, in cases like cookie production, unauthorized recipe alteration may, at worst, lead to consumer dissatisfaction, unauthorized alteration of recipes used in, for example, pharmaceutical production may have more serious implications. In particular, a recipe alteration that changes the quantities or constituents of a drug may render the resulting drug ineffective or toxic. Additionally, the alteration of drug constituents is not, unlike the quantity of chocolate chips in a cookie, readily detectable because the drug may appear to have the same color and consistency as an unaltered or properly manufactured drug.
In a similar manner, the unauthorized or incorrect alteration of software objects used in safety systems could result in a hazardous condition not being detected or an inappropriate action being taken in response to a hazardous condition, which could be life threatening to those working in or living near the plant, not to mention detrimental to the plant itself. Additionally, a faulty safety system software object could falsely detect a hazardous condition and shut down the plant when no hazardous condition actually exists.
Because plant production lines typically involve significant investment in production capacity, time and/or material, having to scrap a production in progress due to a faulty recipe or a faulty activation of the safety system may have a substantial adverse financial impact on the entity carrying out the production run as well as any other entities that expect to receive product produced by the production run. For example, recipes for making products that involve fermentation such as wine, beer, cheese, etc. often require weeks or months of process time as well as substantial material investments.
Typically, recipes for process control systems, as well as other software modules or objects including safety system software objects are written by an engineer or scientist who requests various entities such as, for example, research or production groups, to approve the recipe or the safety system software before it is downloaded to the process control system or the safety system. However, the approval process for process control system software is typically carried out by circulating a memorandum or a request for approval and, in some cases, by requesting input in more informal manners. Additionally, there is rarely an impediment, other than a working knowledge of the process control system and the recipes and other software objects implemented therein, to prevent downloading unapproved software to the process control system or the safety system for use on-line within the process plant.
In facilities employing a safety instrumented system, such as oil and gas refining, etc. there has been an attempt to implement standard operating procedures (SOPs) that require one or more individuals from the organization to manually denote their approval of particular piece of software before the software may be executed in a production system. In fact, the draft standard IEC 615511 requires such approval, in addition to defining different approval levels for differing safety integrity levels (SIL). For example the validation plan for a facility may include SOPs requiring safety functions that are to be executed by the safety instrumented system to be approved by a peer in the same department if the SIL is level 2 or below and by a peer in a different department if the SIL is level 3 or above.
As is known, a SIL is a measure defined in the IEC 61508 standard which defines the integrity of a system with respect to how well the system can be counted on to do what it is supposed to do when it is supposed to do it. More particularly, the SIL is defined by the average probability of failure on demand (PFDavg). The risk reduction factor, which is related to the reciprocal of the PFDavg, defines the difference between the process risk before a safety instrumented function is used and the “tolerable level” of risk which much be achieved for that process or piece of equipment. Basically, the risk reduction factor is the “unmitigated risk” without a safety instrumented function divided by the established “tolerable risk”. Both the risk reduction factor and the SIL are defined for each different safety instrumented function within a safety system, wherein an individual safety instrumented function is designed to identify a need and then act to bring the system to a safe state for each hazard scenario.
In facilities where a safety instrumented function approval process has been implemented, approvals are typically handled using one of two possible approaches including a manual approach and an electronic approach. In the manual approach, a printed copy of the software object (i.e., a printed copy of the safety function software) to be approved is manually routed to each of the approvers for review, and all approval signatures are collected manually in a paper format. In the electronic approach, an electronic document management system is used to route an electronic version of the software object (i.e., a series of screen captures or other text and graphical based documentation that describes the software) to each of the required approvers for review. In this case, all approval signatures are collected in an electronic format.
However, there are serious short-comings with both of these approaches. In particular, there is no direct linkage between the document approval process and the safety instrumented system where the software executes. Because the document approval process occurs outside of the safety instrumented system, approvers are unable to review the software object they are being asked to approve in its native environment (e.g., within the safety instrumented system) and, as a result, there may be issues with respect to the accuracy of the document being reviewed. Furthermore, because the document approval process occurs outside of the safety instrumented system or the design system associate therewith, there are no mechanisms within the safety instrumented system that can guarantee that an unapproved software object cannot be executed until all approvals are in place or that can guarantee that all prior approvals for a software object are revoked (i.e., that the software goes to the unapproved state) if a change is made to the software object.
Additionally, a separate approval and safety design system makes it impossible for the system to keep a record of approvals within the software development audit trail for the software object. Moreover, because the approval system is not linked to the safety instrumented system, both systems must be independently validated, which is time consuming and repetitive.